Until this commit, we had no notion of rigid type variables
in Gradualizer. All type variables were treated as flexible
and thus errors in polymorphic functions were not discovered.
Even obvious errors like
    -spec id(A) -> A.
    id(_X) -> banana.
were left unreported.

This commit adds a new syntactic form of `type()`:
`{rigid_var, anno(), atom()}`. All type variables mentioned
in a spec are convert to rigid_vars during typechecking
of the particular function. Rigid type variables have no
subtypes or supertypes (except for itself, top, none(),
and any()), and therefore we treat them as types we know
nothing about (as they can be anything; their type
determines the caller, not the callee).

I've also added some missing cases to `subst_ty/2`.

All these function coming from the paper "Bidirectional Typing
for Erlang" (N. Rajendrakumar, A. Bieniusa, 2021) require
higher-rank (at least rank-2) polymorphism. To be able to
have higher-ranked polymorphism, we would have to be able to
express inner quantifiers. We don't have that in the typespec
syntax, so the traditional way of interpreting type variables
in specs is to treat them all as quantified at the top-level.

Authors of the paper took a non-standard approach, to quote it:

    Type specifications in Erlang consider all type variables
    as universal and thus restrict the types to prefix or rank-1
    polymorphism.

    For allowing higher-rank polymorphism, we are interpreting
    the type specification differently, namely we are adding
    the quantifier to the type variable with the smallest scope.

    -spec poly_2(fun((A) -> A)) -> {boolean(), integer()}.

    For example, the type spec for function poly_2 above is
    interpreted as
        (∀a.(a) → a) → {boolean(), integer()}
    instead of
        ∀a.((a → a) → {boolean(), integer()})

I argue that this interpretation of type variables would
be confusing for users. Additionally, I think that there
is not much value in having higher-rank polymorphism in
a dynamically/gradually typed language. In Haskell, it
is useful for sure (even though one does not encounter
it very often) but this is because there is a strict
typechecker that doesn't accept anything you cannot type
well. Here, in Erlang, if you ever come to a situation
where you need higher-rank polymorphism (and I think it
is quite unlikely), you can always fallback to any().